Application Load Balancer起動直後のENIを観察してみた
いわさです。
Application Load Balancer(ALB)はAWSでWebシステムを構築する上ではよく利用するサービスだと思います。
先日CloudFormationでALBとEC2を同時に作成した際に想定してなかった挙動をしたので少し観察してみました。
何か得られるものがあったわけではなく、「へー、こんな動きしてるんだー」くらいです。
観察のきっかけ:ヘルスチェックのソースIPアドレスが想定していたより多かった
以下のようにパブリックサブネットにALBを配置し、ターゲットグループにEC2インスタンスが直接ぶらさがる構成です。
EC2にはApacheをインストールし、AZは片側1台のみです。
Webサーバーへのアクセスログを確認するためにCloudWatch Logsへ取り敢えず出力しています。
ヘルスチェックの間隔は10秒です。
ALBを配置するパブリックサブネットは 10.0.0.0/24 と 10.0.1.0/24 で2つのAZに用意しています。
テンプレートはこちら
起動後数分のログは以下のようになっています。
起動後直後は1台(10.0.0.19)からのみヘルスチェックリクエストが送信されています。
そして、1分半たつともう1台(10.0.1.124)からもリクエストが送信されました。
なるほど、両AZのALBからヘルスチェックが開始されるまでタイムラグがあるのですね。
と思っていたら、それから更に30秒後に今度は新たなもう1台(10.0.0.206)から送信され始めました。1台目と同じサブネットですね。
ここから10分以上3台からヘルスチェックが送信され続け、その後一番最初にヘルスチェックを開始したENIからのリクエストが送信されなくなります。
ALB作成時のENIは3つ作成されたり4つ作成されたりすることがある
2つのパターン(想定どおりのパターン)
EC2をap-northeast-1aのサブネットにデプロイするよう指定していたとして、ALBデプロイで自動作成される最初のENIが別AZ(ap-northeast-1c)の場合に発生するようです。
あとはこの2つのENIでヘルスチェックしつづけ、直近でのENIの増加はありませんでした。
3つのパターン
何度か作ったり壊したりしているうちに、3つ作成される時のパターンはわかりました。
CloudFormationでALBとEC2を同時に作成して、ALBの1つ目のENIとEC2のAZが同じだった場合は一時的にENIが3つになるようです。
EC2をap-northeast-1aのサブネットにデプロイするよう指定していたとして、ALBデプロイで自動作成される最初のENIが同一AZの場合に発生するようです。
1つ目のENIにパブリックIPアドレスが割り当てられて、ステータスがIn-use
になったのち、ap-northeast-1cでENIの作成が始まります。
その作成中にap-northeast-1aでも追加のENIの作成が始まります。
この時点ではALBの名前解決で取得されるIPアドレスは1つ目のもののみでした。
iwasa.takahito@hoge~ % nslookup hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com Address: 176.34.8.133
その後3つのENIにパブリックIPアドレスが割り当てられると以下のようになります。
iwasa.takahito@hoge ~ % nslookup hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com Address: 52.198.77.29 Name: hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com Address: 52.197.130.184
10分ほど経過すると、最初に追加したENIが削除されます。
4つのパターン
結局再現が出来なかったのですが、一度だけ4つのENIからヘルスチェックが送信されているパターンがありました。
想像ですが、上記の3つのタイミングでアクセスし4つ目が立ち上がったとか・・・ とはいえ、ページを1〜2回表示した程度なので負荷による可能性は低そうです。
このALB+EC2の作成と削除を10回近く行ったと思いますが、4つのパターンは1回のみでした。
1つのパターン
ちなみに、ターゲットグループにインスタンスが1台も紐付いていない場合はALBのENIは1つになります。
知らなかった。
インスタンスがターゲットグループにぶら下がると、ALBがENIを作成してヘルスチェックを開始するような仕組みになってるみたいですね。
自動でENIを生成するように制御できるのか
ENIを削除またはデタッチ
片方のAZのENIを削除もしくはデタッチすると、空いたAZでENIを自動生成してくれるかもと思い試してみました。
ALBからENIのデタッチは出来ませんでした。
強制デタッチも失敗しました。
デタッチ出来ないということで削除も出来ませんでした。
ヘルスチェックENIのひとつの通信を遮断した場合はどうなるのか
それぞれのAZのENIからヘルスチェックが送信されていましたよね。
もしかして成功/失敗のENIが混在していると、新しくENIを生成してくれたりするんじゃないかと思って試してみました。
ACLで対象IPアドレスをブロックしました。
ヘルスチェックステータスがUnHealthy
にはなりましたが、ENIは自動生成されませんでした。
このあたりでENIが自動生成されるとパブリックIPアドレスを強制的に変えるなど出来ておもしろいかなと思ったのですが難しそうでした。
さいごに
これらの内容は知っている方は当然抑えられている仕様かもしれませんが、明確なドキュメントが見つからず、せっかくなので検証結果を載せてみました。
もしこれらの挙動の背景などご存知の方がいらっしゃればこっそり(@Tak1waまで)教えてください。